home *** CD-ROM | disk | FTP | other *** search
/ BBS Toolkit / BBS Toolkit.iso / wildcat / wctutor.zip / PROTO.HLP < prev    next >
Text File  |  1992-06-08  |  8KB  |  154 lines
  1.  ┌───────────────────────────────────────────────────────────────────────────┐ 
  2.  │  Quick Reference         File Transfer Methods                 Protocols  │ 
  3.  └───────────────────────────────────────────────────────────────────────────┘ 
  4.  
  5.    WILDCAT! offers a wide selection of available file transfer protocols
  6.    internal to the software.  These protocols are what's used to allow files
  7.    to be transmitted from the BBS to your PC.
  8.  
  9.       XMODEM/CRC  - 128 byte block size, medium efficiency
  10.       1K-XMODEM   - 1,024 byte block size, medium efficiency
  11.       YMODEM      - 1,024 byte block size, batch transfer capability
  12.       YMODEM/G    - 1,024 byte block size, reliable connect required
  13.       1K-XMODEM/G - 1,024 byte block size, reliable connect required
  14.       ZMODEM      - Variable byte block size, crash recovery capability
  15.       KERMIT      - 8 bit data can be transferred in 7 bit form
  16.       ASCII       - Continuous data stream, no error checking
  17.  
  18.    Additional protocols can be added to the system and are referred to as
  19.    EXTERNAL protocols.
  20.  
  21. ┌─────────────── For Detailed Descriptions, select [C]ontinue ────────────────┐
  22. ╘═════════════════════════════════════════════════════════════════════════════╛
  23.  ┌───────────────────────────────────────────────────────────────────────────┐ 
  24.  │  Detailed Description    File Transfer Methods                 Protocols  │ 
  25.  └───────────────────────────────────────────────────────────────────────────┘ 
  26.  
  27.    The file area allows movement of files between the host BBS system and
  28.    the caller's computer.  Downloading is the process of moving files from
  29.    the BBS to the caller, and uploading is moving files from the caller to
  30.    the BBS.
  31.  
  32.    Data transfer can be done in a number of ways in on the BBS.  New error
  33.    checking protocols are being added on a regular basis, and the following
  34.    is a summary of many of those available.
  35.  
  36.    XMODEM FILE TRANSFER
  37.    The BBS supports two variations of the XMODEM protocol,originally
  38.    developed by Ward Christensen, called XMODEM and XMODEM/CRC respectively.
  39.    XMODEM offers the advantage of error checking on a block by block basis
  40.    to assure that the data sent contains no errors.  It does this by adding
  41.    a checksum byte to the end of each 128 byte block of data; the receiver
  42.    calculates its own checksum and compares it to the one received.  If an
  43.    error is detected in the transmission, XMODEM will request that WILDCAT!
  44.    retransmit the block of data.  In addition to the above checksum
  45.    comparison, XMODEM/CRC adds another level of error detection using a
  46.    complex CYCLICAL REDUNDANCY CHECK algorithm.
  47.  
  48.    XMODEM and XMODEM/CRC are slow transfer protocols when compared to many
  49.    others available.  They should only be used when your software supports
  50.    no other protocol.  XMODEM/CRC is preferable to XMODEM due to its greatly
  51.    improved error checking.
  52.  
  53.  
  54.    1K-XMODEM
  55.    This protocol performs exactly like regular XMODEM/CRC, but increases the
  56.    block size to 1024 bytes, hence the name 1K.  It is slightly faster (on
  57.    fairly clean phone lines) than regular XMODEM due to a smaller number of
  58.    blocks being sent, and therefore fewer block checks being made.
  59.  
  60.  
  61.    YMODEM
  62.    YMODEM is a protocol devised by Chuck Forsberg of Omen Technology which
  63.    adds a number of enhancements to protocol based transfer.  Block sizes
  64.    are variable at 128/1024, but 1K is the usual size.  Error checking makes
  65.    use of CRC-16, accurate to 99.99%.  By definition, all YMODEM transfers
  66.    are capable of sending multiple files at one request, with the file size
  67.    and date included in the "header block" sent prior to each file.  YMODEM
  68.    supports multiple file transfer (both down AND up) of up to 99 files with
  69.    WILDCAT!.
  70.  
  71.    CAUTION:  A number of communication programs incorrectly use the term
  72.    YMODEM but actually send using 1K-XMODEM.  This practice is not proper and
  73.    will result in a failure when used with a true YMODEM transfer as used by
  74.    WILDCAT!.
  75.  
  76.    Use of YMODEM, if supported by a caller's software, is recommended over
  77.    XMODEM and 1K-XMODEM for speed, reliability, and features.
  78.  
  79.  
  80.    YMODEM/G
  81.    This variation of YMODEM is available only to callers making a "reliable"
  82.    connection using a modem supporting MNP (Microcom Networking Protocol) or
  83.    the U.S. Robotics ARQ hardware error checking or the most recently
  84.    introduced correction method, V.42/V.42bis.  If a MNP connection is
  85.    detected, WILDCAT! will add this protocol choice (as well as 1K-XMODEM/G)
  86.    to the available options.
  87.  
  88.    MNP is a hardware based system in which the modems perform the actual
  89.    error checking and correction, if needed.  The software such as WILDCAT!
  90.    and Qmodem simply send the information blindly from one system to the
  91.    other using the protocol for block sorting information only.  For this
  92.    reason, these two protocol choices ONLY appear if a MNP connection is
  93.    detected at logon.
  94.  
  95.    YMODEM/G is among the fastest protocols with the exception of the newer
  96.    versions of ZMODEM discussed below.  If you have a modem that supports
  97.    MNP or ARQ, YMODEM/G should be your usual choice on the BBS.  Connections
  98.    using two U.S. Robotics HST modems, with ports locked at 19200 or 38400
  99.    at both ends, results in throughput in excess of 1725 characters per
  100.    second (equivalent of over 14,400 bps)!  YMODEM/G also supports multiple
  101.    file transfer (both down AND up) of up to 99 files at on time.
  102.  
  103.  
  104.    1K-XMODEM/G
  105.    This version of 1K-XMODEM makes use of MNP hardware error correction to
  106.    do away with the block-by-block checking in the normal version.  The
  107.    result is a very fast single file transfer protocol for use if YMODEM/G
  108.    is not readily available.
  109.  
  110.  
  111.    ZMODEM
  112.    This is another protocol developed by Chuck Forsberg.  It is a "streaming
  113.    protocol", one which sends variable sized blocks of data with CRC-32 error
  114.    checking for an accuracy of 99.9999%, but does not wait for an
  115.    acknowledgment from the receiving computer.  The sending system assumes
  116.    data received is OK unless a repeat request is sent for a specific block.
  117.    This streaming activity tends to make ZMODEM one of the fastest protocols
  118.    available (but slightly slower than Ymodem/G or 1K-Xmodem/G).  ZMODEM also
  119.    supports multiple file transfer capability, and should be considered in
  120.    situations where MNP is not available, or another batch transfer protocol
  121.    cannot be used.  Zmodem also has the unique capability to resume file
  122.    transfers that have been aborted for some reason and thus only partially
  123.    completed.  This is called crash recovery.
  124.  
  125.  
  126.    KERMIT
  127.    This protocol's main claim is not speed, but rather its ability to
  128.    interact with many types of computers from mainframes to micros.  It can
  129.    cope with systems limited to seven-bit characters even when the data to
  130.    be transmitted is in eight-bit form.  All characters to be sent are
  131.    translated into standard printable characters and reconstructed on the
  132.    receiving end.
  133.  
  134.    While not terribly efficient, it is sometimes an absolute necessity for
  135.    data transfer involving different types of systems and terminal types.
  136.    It is not normally recommended for PC to PC transfers.
  137.  
  138.  
  139.    ASCII DATA CAPTURE
  140.    ASCII transfer is simply the sending of information as characters, and is
  141.    limited to 7 bit information.  The transfer of files in ASCII mode can be
  142.    done if your system is capable of any type of data capture.  ASCII
  143.    transfer is limited, and some sort of error checking protocol is required
  144.    if you intend to transfer files with extensions of EXE, OBJ, COM, ARC or
  145.    ZIP, as well as tokenized BASIC programs and files containing the IBM PC
  146.    special ASCII characters (ones with ASCII values above 128).  These files
  147.    cannot be transferred in ASCII mode since ASCII transfer is only 7 bit and
  148.    these types of files require the full 8 bit transfer of the data, with no
  149.    translation of the contents of the file.
  150.  
  151.  
  152. ┌────────────────────────── End of Help Information ──────────────────────────┐
  153. ╘═════════════════════════════════════════════════════════════════════════════╛
  154.